Expandable dynamic folder using CSS instead of Javascript ?

[Mel]

if you know of dynamic expandable folder using CSS and display function,
please drop me a note

Yours,
Mel

[Harlan Messinger]

"Mel" <jm**@redolive.com> wrote:

if you know of dynamic expandable folder using CSS and display function,
please drop me a note

Since CSS doesn't provide a way for interaction with one element to
alter the style of another element, this can't be done.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Chris Morris]

Harlan Messinger <hm*******************@comcast.net> writes:

"Mel" <jm**@redolive.com> wrote:

if you know of dynamic expandable folder using CSS and display function,
please drop me a note

Since CSS doesn't provide a way for interaction with one element to
alter the style of another element, this can't be done.

<div class="upper">
<div class="lower">
</div>
</div>

..lower { /* default style */ }
..upper:hover .lower { /* altered style */ }

Browser support varies, obviously. I'd hesitate to say the request
above can't be done, but it'd take quite a bit of effort to get a good
implementation of it if it is possible.

--
Chris

[Harlan Messinger]

Chris Morris <c.********@durham.ac.uk> wrote:

Harlan Messinger <hm*******************@comcast.net> writes:

"Mel" <jm**@redolive.com> wrote:

>if you know of dynamic expandable folder using CSS and display function,
>please drop me a note
Since CSS doesn't provide a way for interaction with one element to
alter the style of another element, this can't be done.

<div class="upper">
<div class="lower">
</div>
</div>

.lower { /* default style */ }
.upper:hover .lower { /* altered style */ }

Um. As far as mouse-overs are concerned, I was technically mistaken.
This still isn't practical though--the altered style goes away as soon
as you move the mouse away from the upper div. That's no no good for
an expanding folder motif, which calls for persistence of the expanded
state. It also calls for activation by click rather than by hover. It
needs basically to maintain state--open or closed--for the contents of
each folder, and CSS doesn't provide this.

Browser support varies, obviously. I'd hesitate to say the request
above can't be done, but it'd take quite a bit of effort to get a good
implementation of it if it is possible.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

[Matt Kruse]

Mel wrote:

if you know of dynamic expandable folder using CSS and display
function, please drop me a note

As other posters have mentioned, implementing a tree structure with pure CSS
isn't practical, given that it can't act on mouse clicks, etc.

I have a tree solution which uses javascript to capture events, but then
uses CSS to hide/display nodes, style the +/- boxes, etc. You can test it
out at http://www.JavascriptToolbox.com/mktree/

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Jonas Smithson]

Matt Kruse wrote:

I have a tree solution which uses javascript to capture events,
but then uses CSS to hide/display nodes, style the +/- boxes, etc.
You can test it out at http://www.JavascriptToolbox.com/mktree/

Um, using IE5.1 on Mac OS9.2.2, after reading the text about how it
degrades gracefully, I clicked the "Collapse All" link... and up popped
a JavaScript error message:

Microsoft JScript runtime error:
Line: 28
Char: 100
Error: 'nodeClosedClass' is undefined

Then the browser crashed. I re-launched the browser, and tried again...
and the same thing happened again.

I'm not trying to start a JS discussion in a CSS newsgroup, but since
you mentioned it...

[Matt Kruse]

Jonas Smithson wrote:

Um, using IE5.1 on Mac OS9.2.2, after reading the text about how it
degrades gracefully, I clicked the "Collapse All" link... and up
popped a JavaScript error message:

Hmm, I've not seen that before (since I don't have IE5.1 on mac to test
with). I'll keep it noted and try to fix it if I can get access to that
browser to test. IE on Mac tends to have quite a few javascript quirks, and
it's annoying to code for. Especially versions < 5.5. You may want to
upgrade :)

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

IE on Mac tends to have quite a few javascript quirks, and it's
annoying to code for. Especially versions < 5.5. You may want to
upgrade :)

(ahem) Upgrade to what, exactly? There is no version greater than 5.2
for the Mac. And there won't be, either. MS announced some time ago that
would not develop any new versions of their browser for the Mac platform.

--
Brian (remove ".invalid" to email me)

[Matt Kruse]

Brian wrote:

(ahem) Upgrade to what, exactly? There is no version greater than 5.2
for the Mac.

Ah, you're right, 5.2.1 is the latest version. I get the minor versions
mixed up sometimes (since I avoid macs at all costs). No one should be using
IE on mac anymore anyway, IMO. There are better options available :)

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

No one should be using IE on mac anymore anyway, IMO. There are
better options available :)

It's not up to us, of course, which browser people use -- perhaps they
must use a certain browser per company rules, perhaps they like what
they have. In any case, IE 5.x/Mac is not the worst browser they could
be using. It has fairly good css support, better than the Win versions.
The problem is that its bugs are different then those of other browsers.
But every browser has its unique little quirks.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Jonas Smithson]

Matt Kruse wrote:

Ah, you're right, 5.2.1 is the latest version.
That's for OSX. The latest (and, apparently, last) version of IE for
classic Mac is 5.1, the version I'm using. I can't use Safari because
it's not available for classic Macs (i.e. OS9) and I only occasionally
run OSX. And even according to Apple's own (not impartial) figures,
half of all Mac users are still using classic Macs. I suspect the
number may be higher (Apple has reasons to exaggerate the rate of OSX
adoption). Since AFAIK most classic Mac users use IE5, my (admittedly
rough) guesstimate is that ten million people or more may be using
IE5.1 on a Mac.
I get the minor versions mixed up sometimes
(since I avoid macs at all costs).
No one should be using IE on mac anymore anyway, IMO.
There are better options available :)
First of all, since you "avoid Macs at all costs," I don't think you're
in a position to tell Mac users what browsers we "should be using" --
or tell us anything else about how to use our computers, for that
matter. How would you know "there are better options available" if you
don't use Macs?

Brian wrote: It's not up to us, of course, which browser people use...
Absolutely right.

Brian also wrote: In any case, IE 5.x/Mac is not the worst browser they could
be using. It has fairly good css support, better than the Win
versions. The problem is that its bugs are different then
those of other browsers. But every browser has its unique
little quirks.
Right again.

The fact is that Explorer 5 launches almost instantaneously on my Mac,
while Netscape 7 takes forever to launch; and that MacIE5 has the most
pleasant interface and general personality of any browser I've used on
either my Mac or my PC. Mac IE5 has nothing to do with WinIE5, by the
way -- the Microsoft development teams are separate and neither the
feature sets nor the version numbers correlate across platforms. Mac
IE5 appears to be a more modern browser in many ways than Win IE6.

Matt Kruse wrote: Hmm, I've not seen that before (since I don't have
IE5.1 on mac to test with). I'll keep it noted and try
to fix it if I can get access to that browser to test.
IE on Mac tends to have quite a few javascript quirks,
and it's annoying to code for.
Sorry, I can't make any sense out of that statement. If you don't have
MacIE5 to test your JavaScript against, how would you even know it has
"quite a few javascript quirks"? How could it be "annoying to code for"
if you haven't coded for it? (I *have* coded JavaScript with no special
problems in MacIE5, but to be fair, I'm not a JS expert and I'm sure
your JS coding is much more complex than mine.)

I have no particular reason to defend Microsoft or its browsers, by the
way. I'm not a fan of theirs; I'm just trying to be balanced here.
MacIE5 is a buggy browser when it comes to CSS (in fact I recently
tried to start another thread on that but nobody responded) but it's no
more buggy with CSS than WinIE6 is. I tend to agree with Brian -- the
Mac version may be even more compliant overall -- the bugs are just
different. Despite all that, I actually would run NS7 on my Mac just to
get the increased CSS compliance (despite the slowness and despite my
fondness for the IE5 interface) except for one thing: I'm most
interested in testing my Web pages to see what other users are seeing,
not in what browser works best for *me*. That means running the most
common browsers, which, like it or not, come from Microsoft -- on both
Macs and PCs.

Finally, saying in effect (that is, implying) "oh, it's just a ______
problem" (insert name of computer platform, browser, etc.) makes as
little sense when talking about JavaScript as it does when talking
about CSS. The extreme irony here is that you yourself, Matt, have
taken (IMNSHO) an admirable and even courageous stand for realism in
other threads. Forgive me (if you can) for throwing your own words back
at you from another thread:

Matt Kruse wrote: Just because something is "superior" doesn't mean it will actually _work_!
Big sites need to support as many browsers as possible....

Yes, indeed. And that goes for JavaScript as well as CSS.
Broad-spectrum testing, in my opinion, is even more important than
validation (I have a feeling I'm going to get flamed for saying that --
but not by you!). Although MacIE5 has some problems with CSS
compliance, the vast majority of JavaScript code I encounter online
works just fine in MacIE5 -- and even when it doesn't, it almost never
crashes the browser, as yours did.

[Brian]

Jonas Smithson wrote:

Matt Kruse wrote:

Ah, you're right, 5.2.1 is the latest version.
That's for OSX. The latest (and, apparently, last) version of IE for
classic Mac is 5.1, the version I'm using.

Does that mean that 5.2.1 is a port of 5.1? I thought there were minor
changes in css parsing.
I can't use Safari because it's not available for classic Macs (i.e.
OS9) and I only occasionally run OSX.
Too bad; it seems like a nice browser. Tabbed browsing alone makes it
attractive.
And even according to Apple's own (not impartial) figures, half of
all Mac users are still using classic Macs.
If true, that should read *already* half of all Mac users are using OSX;
that's a very high rate penetration rate for software that is not *so* old.
I suspect the number may be higher (Apple has reasons to exaggerate
the rate of OSX adoption).
Well, there's always that possibility.
The fact is that Explorer 5 launches almost instantaneously on my
Mac, while Netscape 7 takes forever to launch;
It is a suite of applications, not just a browser. Still, I found it was
reasonably fast when I tried it out while housesitting for a couple of
professors.
Mac IE5 has nothing to do with WinIE5, by the way

Totally different code base. They share only a name. While IE/Mac's bugs
can be annoying, at least hiding css from it is trivial. @media rule
does the trick. And I've found that I have very little to hide from it.
Though, I must admit, I don't get the chance to test very often on one,
and I'm usually unpleasently surprised when I do.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Jonas Smithson]

Brian wrote:

Does that mean that 5.2.1 is a port of 5.1? I thought there were minor
changes in css parsing.

I don't know if it's a port, but it may well be. Mac apps can fall into
any one of three broad coding categories:

Classic apps: old Mac apps run in a "classic compatibility" sandbox
when launched under OSX (i.e., OSX essentially runs the old OS on top
of the new one). Some old apps can't run this way at all, but most
will. If they crash, they only bring down the sandbox, not the main OS.

Carbon apps: usually indicates a Classic >> OSX port, so that the app
can run natively under OSX and take advantage of some but not all of
OSX's advanced features. I think most current OSX apps are Carbon.

Cocoa apps: a true OSX app, written from scratch, with access to the
full API.

AFAIK you can also run many straight Unix apps (since Mac OSX is mostly
FreeBSD Unix under the hood), if you know Unix command line and don't
mind bypassing the OSX GUI.

I don't know which category the various browsers fall into, and a quick
Google search I just did didn't enlighten me. IE5.1 is clearly Classic.
My guess is that IE5.2.1 is a Carbon port, and Safari, Chimera, and
some others are Cocoa, but I don't really know. There are versions of
Netscape 7 for both OS9 and for OSX, but I don't know what their
relationship is or whether they parse CSS the same.

I wish I had some statistics (even guesstimates) on the installed base
of the various Mac browsers, so I'd know what to think about testing
against. I came across some Web site (don't remember where) that
claimed to put up screen shots of your Web pages as they'd appear in a
whole range of browsers, but it was a paid service and I didn't try it.

[Brian]

Jonas Smithson wrote:

IE5.1 is clearly Classic. My guess is that IE5.2.1 is a Carbon
port, and Safari, Chimera, and some others are Cocoa, but I don't
really know.
Chimera is definitely Cocoa. I remember reading that on an old version
of the Mozilla site. I'd imagine Safari is, too.
I wish I had some statistics (even guesstimates) on the installed
base of the various Mac browsers, so I'd know what to think about
testing against.

If I had a Mac, I'd test with IE 5.x and Safari. Those are probably
the most important. Chimera/Netscape/Mozilla would be bonus testing.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Matt Kruse]

Jonas Smithson wrote:

The latest (and, apparently, last) version of IE for classic Mac is 5.1
Thanks for the clarifications - I'm certainly not an expert on mac browsers!
First of all, since you "avoid Macs at all costs," I don't think
you're in a position to tell Mac users what browsers we "should be
using"
Just IMO. Granted, I don't know all the OS versions, but I do have a couple
of macs that I can test with, and in my experience, I found IE to be very
frustrating on some basic issues which I faced repeatedly.
Matt Kruse wrote:

Hmm, I've not seen that before (since I don't have
IE5.1 on mac to test with). I'll keep it noted and try
to fix it if I can get access to that browser to test.
IE on Mac tends to have quite a few javascript quirks,
and it's annoying to code for. Sorry, I can't make any sense out of that statement. If you don't have
MacIE5 to test your JavaScript against, how would you even know it has
"quite a few javascript quirks"?

I don't have exact version 5.1 available to me, but I've tested with other
versions. I'm not going to go out and buy a mac just to test with, so when
it is available to me I test the versions I can and hope the rest work.
MacIE5 is a buggy browser when it comes to CSS (in fact I recently
tried to start another thread on that but nobody responded) but it's
no more buggy with CSS than WinIE6 is.
I've not done extensive testing with css, but in one instance I had a simple
rule like
..class { font-weight:bold; }
IIRC, and it totally crashed IE on mac. If I took that rule out of the
stylesheet, it didn't crash. Things like that (and some of my own js
testing) lead me to believe that IE on Mac has some peculiar problems, but
I'll admit that these beliefs may not be 100% accurate. Hey, no one can
fully understand all the quirks of all the browsers out there! ;)
Finally, saying in effect (that is, implying) "oh, it's just a ______
problem" (insert name of computer platform, browser, etc.) makes as
little sense when talking about JavaScript as it does when talking
about CSS.
Depends. If a perfectly valid rule or syntax causes a specific browser to
crash, then I always believe that it's the browser's fault, and it shouldn't
be catered to (unless it's IE on Win, since that's the vast majority of
users). If my tree code and css is valid (not sure if it is, never validated
it) then if it crashed IE on Mac, that doesn't bother me much. I'd like to
find a fix, but testing and debugging in that environment is so difficult
for me that I usually have to rely on others to find the exact source of the
problem and hopefully find a fix.
The extreme irony here is that you yourself, Matt, have
taken (IMNSHO) an admirable and even courageous stand for realism in
other threads.
Glad someone at least understood my view ;)
Matt Kruse wrote:

Just because something is "superior" doesn't mean it will actually
_work_! Big sites need to support as many browsers as possible.... Yes, indeed. And that goes for JavaScript as well as CSS.

I agree completely, and I do as extensive of testing as I can. Most of my
code is extremely cross-browser even when performing tasks which are quite
complex. But the truth is, you can't test everywhere. I would love to get my
tree to work correctly - or at least not crash! - in IE/Mac. If you have any
suggestions, please do let me know.
Broad-spectrum testing, in my opinion, is even more important than
validation (I have a feeling I'm going to get flamed for saying that
-- but not by you!).

Certainly not by me. I agree completely!
Now, if only there was a way to test mac browsers without actually owning a
mac :)

--
Matt Kruse
Javascript Toolbox: http://www.JavascriptToolbox.com/

[Brian]

Matt Kruse wrote:

I've not done extensive testing with css, but in one instance I had
a simple rule like
.class { font-weight:bold; }
IIRC, and it totally crashed IE on mac.
Unless you can provide a test case, this offers us very little.
I'll admit that these beliefs may not be 100% accurate. Hey, no one
can fully understand all the quirks of all the browsers out there!
;)

Perhaps you can understand why someone might take you to task for
making unverifiable claims about a browser which you have little
experience with.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/